通过对 Service Worker 的系统学习，我们知道它为 Web 的离线处理提供了支持，但它仍需要配合离线存储、后台同步等技术来充分挖掘、发挥其威力。在本章节中，我们将对离线存储进行讨论，希望通过本章节的学习，大家可以掌握以下内容：

离线存储方案对比。

• IndexedDB 的基本使用。
• Cache API 的基本使用。

# 离线存储方案对比

如图所示，在 Chrome Devtools -> Application -> Storage / Cache 标签下，我们可以看到不同的离线存储方案，究竟这些方案有什么差异，我们又该使用哪些方案来为 Service Worker 提供底层服务，本节将一一为大家说明。

# Cookie

Cookie 是服务器发送并保存到客户端的一小块数据，目的是为了解决无状态 HTTP 协议下无法验证两个请求来自同一会话的问题，主要特点为：

• 无法跨域访问。
• 存储数据格式单一。
• 接口同步访问。
• 存储空间过小（一般为 4 KB）。
• 生命周期一般由服务器设定，如果由浏览器生成，一般在浏览器关闭后失效。
• 每次请求都会自动携带 Cookie 信息，如果存放的数据过多，将会带来额外的性能开销。
• 无法在 Web Worker 及 Service Worker 环境下访问。

# LocalStorage 和 SessionStorage

LocalStorage、SessionStorage 是 HTML5 引入的离线存储技术，主要特点为：

• 无法跨域访问。
• 存储数据格式单一。
• 接口同步访问。
• 存储空间相对于 Cookie 有所增加（一般为 5 MB）。
• 生命周期 LocalStorage 为永久，SessionStorage 则随着页面关闭而失效。
• 仅存在客户端中，不参与服务端通信。
• 无法在 Web Worker 及 Service Worker 环境下访问。

至此，我们对 Cookie、LocalStorage 以及 SessionStorage 进行了简单说明，由于其均无法在 Service Worker 环境下访问且 Service Worker 的离线存储要求能够存储大量、具有不同格式的数据，故上述存储方案均无法使用。它们的主要使用场景为：

• 由于每次请求都会自动携带 Cookie 信息，优先使用 Cookie 来保存用户登录状态信息。
• 也正是由于每次请求都会自动携带 Cookie 信息，除用户登录状态之外任何会话（比如购物车、游戏分数等）信息优先使用 LocalStorage 或 SessionStorage

# Web SQL 和 IndexedDB

Web SQL、IndexedDB 同样是 HTML5 引入的离线存储技术，主要特点为：

• 无法跨域访问。
• 可存储丰富的数据格式。
• 接口异步访问（基于事件）。
• 存储空间较大（一般不少于 250 MB）。
• 生命周期为永久。
• 仅存在客户端中，不参与服务端通信。
• 能够在 Web Worker 及 Service Worker 环境下访问。

总的来说，Web SQL、IndexedDB 是关系型数据库、非关系型数据库在客户端的各自实现，其所支持的丰富数据格式、较大的存储空间以及可在 Service Worker 环境下访问的特性均符合 Service Worker 对底层技术的要求，但由于 Web SQL 已被 W3C 废弃且浏览器支持情况不甚理想，所以我们可选用 IndexedDB 作为 Service Worker 的底层技术支持。

# Application Cache

Application Cache 是 HTML5 引入的旨在提供页面离线访问能力的缓存机制，其使用步骤如下：

• 在文档的 html 标签中设置 manifest 属性以引用 manifest 文件。
• 配置 manifest 文件，在其中设置需要缓存的资源。
• 服务端正确配置 MIME-type。

上述可知，它仅仅提供了一套离线缓存机制，并非离线存储方案。这里之所以提及，因为这是 Web 离线处理的一次尝试，但由于存在各种各样的问题，导致它最终被废弃的命运，这也才会有后来的 Service Worker。其主要问题为：

• 缓存内容存在大小限制（一般为 5 MB）。
• 无法通过编程方式清除缓存，必须用户手动清除。
• manifest 配置文件格式要求比较严格。
• 只要 manifest 配置文件中的资源有一个缓存（更新）失败，将导致全部资源缓存（更新）失败。
• 由于会自动缓存引用了 manifest 的 HTML，这就导致如果改了 HTML 内容，也需要更新版本才能更新。
• 难以实现动态缓存，且一旦出现问题，将难以进行调试。

# CacheStorage

CacheStorage 是 Service Worker 规范的一部分，因此从它出生的那一刻起便决定了它为 Service Worker 提供底层服务的使命。虽然它是 Service Worker 规范的一部分，但依旧可以脱离 Service Worker 单独使用。主要特点为：

• 无法跨域访问。
• 可存储丰富的数据格式。
• 接口异步访问（基于 Promise）。
• 存储空间较大（一般不少于 250 MB）。
• 生命周期为永久。
• 仅存在客户端中，不参与服务端通信。
• 能够在 Web Worker 及 Service Worker 环境下访问。

# 小结

通过上述对比，我们可以使用 IndexedDB 及 CacheStorage 来为 Service Worker 的离线存储提供底层服务，根据社区的经验，它们各自的适用场景为：

• 对于网址可寻址的（比如脚本、样式、图片、HTML 等）资源使用 CacheStorage。
• 其他资源则使用 IndexedDB。
• 完成了技术选型，接下来我们将对 IndexedDB 及 CacheStorage 相关 API 的使用进行简单说明

# IndexedDB 的基本使用

本节我们将通过数据库及数据操作两个方面对 IndexedDB 的使用进行简单说明。

# 数据库操作